Remove false-positive debug assert hits against normative behavior. - #876
Conversation
fac1504 to
b27f9cf
Compare
gavin-dunlap-luminar
changed the title
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #876 +/- ##
==========================================
+ Coverage 63.31% 63.99% +0.67%
==========================================
Files 62 62
Lines 8064 8093 +29
==========================================
+ Hits 5106 5179 +73
+ Misses 2958 2914 -44
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Thank you for noticing. I need to do a small pass on the CI before merging this, which may take a little while, but this looks good and I will get around to merging it. |
|
@gavin-dunlap-luminar Unfortunately your branch will need rebasing on main before I can merge it. Would you be able to do that or give me permissions to do that? |
b27f9cf to
61245d8
Compare
I've rebased. |
2 participants
Description
Port::set_recommended_stateasserts !default_ds.slave_only in theM1 | M2arm. The assertion is wrogn and it panics debug builds of any slave-only instance on a conformant network. According to Figure 31 of IEEE 1588-2019, there is a connection from a BMC_MASTER recommendation to LISTENING. A slave-only instance is recommended M1 or M2 whenever it is the best clock in its domain (the only device powered up so far, or with an aged out grandmaster).Impact
Release builds are unaffected. Debug builds of slave-only instances panic on the first BMCA cycle that finds no better master. This makes
slave_only: trueunusable unless debug assertions are disabled for the whole crate. Encountered in the wild while utilizing this crate.